{"id":434,"date":"2021-06-08T15:46:08","date_gmt":"2021-06-08T13:46:08","guid":{"rendered":"https:\/\/compliance.toscana.it\/wordpress\/?post_type=scenario&#038;p=434"},"modified":"2021-06-14T13:35:42","modified_gmt":"2021-06-14T11:35:42","slug":"sst-wsdl-busta-eventi-sanitari-b98","status":"publish","type":"scenario","link":"https:\/\/compliance.toscana.it\/wordpress\/it\/scenari\/sst-wsdl-busta-eventi-sanitari-b98\/","title":{"rendered":"SST &#8211; WSDL Busta Eventi Sanitari B98"},"content":{"rendered":"\n<p>Il presente scenario descrive le specifiche della busta di trasporto degli eventi sanitari, di seguito chiamata anche \u201cEvento Clinico\u201d. Descrive inoltre il formato della busta e il suo utilizzo per ogni tipo di interazione (one-way, request-response sincrona e asincrona) che realizza scenari di cooperazione per domini applicativi diversi.<\/p>\n\n\n\n<p>busta di trasporto per gli eventi clinici, in seguito chiamata anche \u201d<em>Evento Clinico<\/em>\u201d. Un <em>Evento Clinico<\/em> \u00e8 composto da due elementi:<\/p>\n\n\n\n<ul><li>una <em>Intestazione<\/em> che contiene le informazioni che riguardano la trasmissione e la gestione del messaggio (ad es. un identificativo della trasmissione e del mittente, la data di trasmissione, la scadenza) ed \u00e8 indipendente dal particolare contesto applicativo. Come mostrato in Figura 1, l\u2019intestazione ha un formato diverso per i messaggi di richiesta, risposta o di acknowledge;<\/li><li>un <em>Corpo<\/em> in cui \u00e8 inserito il contenuto applicativo del messaggio. Il <em>Corpo<\/em> \u00e8 obbligatorio per i messaggi di richiesta e risposta, mentre \u00e8 opzionale per i messaggi di acknowledge;<\/li><\/ul>\n\n\n\n<p>Il formato dell\u2019evento clinico \u00e8 mostrato nella figura seguente.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large is-resized\"><img loading=\"lazy\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image.png\" alt=\"\" class=\"wp-image-439\" width=\"546\" height=\"138\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image.png 546w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-300x76.png 300w\" sizes=\"(max-width: 546px) 100vw, 546px\" \/><figcaption>Formato del messaggio &#8220;Evento Clinico&#8221;<\/figcaption><\/figure>\n\n\n\n<p>Si osserva che l&#8217;Evento Clinico \u00e8 anche caratterizzato da un numero di versione (intero o decimale). In generale il numero di versione dovrebbe essere <strong>numero_rfc.versione_rfc<\/strong>.<\/p>\n\n\n\n<p>Il formato della intestazione di un Evento Clinico utilizzato per l\u2019invio di una <em>Richiesta<\/em>.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><img loading=\"lazy\" width=\"292\" height=\"401\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-1.png\" alt=\"\" class=\"wp-image-440\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-1.png 292w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-1-218x300.png 218w\" sizes=\"(max-width: 292px) 100vw, 292px\" \/><figcaption>Messaggio \u201cEvento Clinico \u2013 Richiesta\u201d<\/figcaption><\/figure><\/div>\n\n\n\n<p><strong>Intestazione del messaggio di richiesta, utilizzata sia nelle interazioni di tipo richiesta\/risposta, sia nelle interazioni di tipo &#8220;one-way&#8221;.<\/strong><\/p>\n\n\n\n<p>L\u2019intestazione \u00e8 composta dalle informazioni riportate nella lista seguente. Si osserva la presenza di un elemento generico astratto (<em>\u201cIntestazione\u201d<\/em>) che include gli elementi comuni alle intestazioni dei messaggi di richiesta, risposta e acknowledge e un elemento concreto (<em>\u201cIntestazioneRichiesta\u201d<\/em>) che lo specializza includendo le informazioni specifiche per il tipo di messaggio:<\/p>\n\n\n\n<ul><li><em>QIdMessaggio<\/em>: codice identificativo univoco qualificato del messaggio. Si osserva che questo codice non deve essere mai utilizzato due volte anche in caso di ritrasmissione del messaggio. L\u2019utilit\u00e0 del codice \u00e8 quella di consentire ad altri messaggi (risposta o messaggi di ack) di riferirsi a questa comunicazione. L\u2019elemento \u00e8 costituito da un codice OID di dominio che identifica il mittente e un identificativo locale, come mostrato nella figura seguente:<\/li><\/ul>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><img loading=\"lazy\" width=\"175\" height=\"73\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-3.png\" alt=\"\" class=\"wp-image-442\"\/><\/figure><\/div>\n\n\n\n<p>Il codice OID del dominio identifica anche il dominio a cui il ricevente dovr\u00e0 restituire l\u2018eventuale risposta o acknowledge. Il codice OID \u00e8 strutturato in \u201cradice\u201d (che risponde al formato ISO-ITU OID) ed \u201cestensione\u201d.<\/p>\n\n\n\n<p>Per le ASL, \u00e8 opportuno (bench\u00e8 non obbligatorio) che il codice OID del dominio sia valorizzato nel modo seguente:<\/p>\n\n\n\n<ul><li>2.16.840.1.113883.2.9.2.90101.4.5 per ASL 1 Massa Carrara<\/li><li>2.16.840.1.113883.2.9.2.90102.4.5 per ASL 2 Lucca<\/li><li>2.16.840.1.113883.2.9.2.90103.4.5 per ASL 3 Pistoia<\/li><li>2.16.840.1.113883.2.9.2.90104.4.5 per ASL 4 Prato<\/li><li>2.16.840.1.113883.2.9.2.90105.4.5 per ASL 5 Pisa<\/li><li>2.16.840.1.113883.2.9.2.90106.4.5 per ASL 6 Livorno<\/li><li>2.16.840.1.113883.2.9.2.90107.4.5 per ASL 7 Siena<\/li><li>2.16.840.1.113883.2.9.2.90108.4.5 per ASL 8 Arezzo<\/li><li>2.16.840.1.113883.2.9.2.90109.4.5 per ASL 9 Grosseto<\/li><li>2.16.840.1.113883.2.9.2.90110.4.5 per ASL 10 Firenze<\/li><li>2.16.840.1.113883.2.9.2.90111.4.5 per ASL 11 Empoli<\/li><li>2.16.840.1.113883.2.9.2.90112.4.5 per ASL 12 Viareggio<\/li><li>2.16.840.1.113883.2.9.2.90801.4.5 per ISPO<\/li><li>2.16.840.1.113883.2.9.2.90901.4.5 per AO Pisana<\/li><li>2.16.840.1.113883.2.9.2.90902.4.5 per AO Senese<\/li><li>2.16.840.1.113883.2.9.2.90903.4.5 per AO Careggi<\/li><li>2.16.840.1.113883.2.9.2.90904.4.5 per AO Meyer<\/li><li>2.16.840.1.113883.2.9.2.90907.4.5 per Fondazione Monasterio \/ IFC-CNR<\/li><\/ul>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><img loading=\"lazy\" width=\"209\" height=\"74\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-2.png\" alt=\"\" class=\"wp-image-441\"\/><\/figure><\/div>\n\n\n\n<ul><li><em>TipoComunicazione<\/em>: Indica la tipologia della comunicazione. Pu\u00f2 assumere i valori seguenti:<ul><li>P = &#8220;Produzione&#8221;. Il messaggio \u00e8 inviato da un sistema di produzione;<\/li><li>T = &#8220;Test&#8221;. Il messaggio \u00e8 inviato da un sistema di pre-produzione\/di staging. Se messaggi di questo tipo sono inviati da un sistema di produzione, il sistema ricevente deve scartare questi messaggi.<\/li><\/ul><\/li><\/ul>\n\n\n\n<ul><li><em>Data<\/em>: la data della trasmissionedel messaggio. Si osserva che questa \u00e8 differente dalla data dell\u2019evento che ha causato la produzione del messaggio che \u00e8 invece riportata (se necessario) all\u2019interno del contenuto applicativo.<\/li><\/ul>\n\n\n\n<ul><li><em>Interazione:<\/em> elemento composto dal numero dell\u2019RFC applicativo di riferimento per la comunicazione e versione RFC e numero dello scenario di riferimento all\u2019interno dell\u2019RFC.<\/li><\/ul>\n\n\n\n<ul><li><em>Destinatario: <\/em>\u00e8 un campo opzionale che individua, attraverso un codice OID, il destinatario dell\u2019evento.<\/li><\/ul>\n\n\n\n<ul><li><em>Scadenza: <\/em>data di scadenza del messaggio. Il sistema ricevente che riceve un messaggio scaduto non deve elaborarlo. Se il mittente accetta la comunicazione di un ack di errore (ModalitaAck=\u2019E\u2019 o \u2018S\u2019), il ricevente deve notificare un opportuno ack con <em>Esito = \u201cR\u201d<\/em> (reject) e <em>CodiceAck = 007<\/em>: \u201cMessaggio non elaborato perch\u00e9 scaduto\u201d. Il campo \u00e8 opzionale e riservato ad usi futuri.<\/li><\/ul>\n\n\n\n<ul><li><em>Priorit\u00e0:<\/em> campo intero che indica la priorit\u00e0 dell\u2019evento. A valore pi\u00f9 alto corrisponde priorit\u00e0 maggiore. Il campo \u00e8 opzionale e riservato ad usi futuri.<\/li><\/ul>\n\n\n\n<ul><li><em>Sequenza: <\/em>numerodi sequenza opzionale del messaggio, di uso interno al dominio applicativo. Non utilizzato attualmente dal livello regionale.<\/li><\/ul>\n\n\n\n<ul><li><em>Modalit\u00e0 di Risposta:<\/em> Indica la modalit\u00e0 di restituzione della risposta al fruitore. Possibili valori sono i seguenti<sup><a href=\"#sdfootnote1sym\"><sup>1<\/sup><\/a><\/sup>:<ul><li>I = &#8220;immediate&#8221; se siamo in un caso di request\/response sincrona (quindi una interazione bloccante per il fruitore);<\/li><li>D = &#8220;deferred&#8221; nel caso di request\/response asincrono ed \u00e8 responsabilit\u00e0 dell&#8217;erogatore inviare la risposta al richiedente;<\/li><li>N = &#8220;none&#8221; nel caso di scenari one way (senza risposta);<\/li><\/ul><\/li><\/ul>\n\n\n\n<p>Si osserva che un erogatore pu\u00f2 supportare un numero ristretto di modalit\u00e0 (al limite una sola). Se la modalit\u00e0 richiesta non \u00e8 supportata si restituisce al mittente un messaggio &#8216;ack&#8217; con <em>Esito = \u201cR\u201d<\/em> (reject) e <em>CodiceAck <\/em><em>=<\/em> 005: \u201cModalit\u00e0 di restituzione della risposta non supportata\u201d.<\/p>\n\n\n\n<ul><li><em>Modalit\u00e0 di Ack: <\/em>indica la modalit\u00e0 di restituzione di un ack e pu\u00f2 assumere i valori:<ul><li>E = &#8220;errore&#8221; l&#8217;ack deve essere restituito al richiedente solo in caso di errore o rifiuto del messaggio;<\/li><li>S = &#8220;sempre&#8221; l&#8217;ack deve essere sempre restituito al richiedente;<\/li><li>M = &#8220;mai&#8221; l&#8217;ack non deve essere mai restituito.<\/li><\/ul><\/li><\/ul>\n\n\n\n<p>Si osserva che se lo scenario \u00e8 di tipo <em><strong>richiesta-risposta sincrona<\/strong><\/em>, il campo viene ignorato dal sistema che riceve la richiesta e l\u2019ack viene sempre restituito (all\u2019interno del messaggio di risposta).<\/p>\n\n\n\n<ul><li><em>QIdEventoParent: <\/em>riferimento opzionale ad un evento. Il campo pu\u00f2 essere utilizzato da un&#8217;Azienda per tracciare internamente la catena di propagazione di propri eventi correlati. Non utilizzato da Regione Toscana.<\/li><\/ul>\n\n\n\n<ul><li><em>Livello:<\/em> campo opzionale che il sistema aziendale pu\u00f2 utilizzare come discriminante per decidere se se l\u2019evento deve essere propagato a Regione Toscana o se deve rimanere internamente all\u2019azienda. In particolare, gli eventi che riportano un <em>Livello<\/em> compreso tra 0 e 10 devono essere inviati anche a Regione Toscana. Quelli che hanno un <em>Livello<\/em> maggiore di 10 sono interni al dominio aziendale.<\/li><\/ul>\n\n\n\n<ul><li><em>Keywords:<\/em> Elenco opzionale di coppie chiave\/valore utili ad un&#8217;indicizzazione dell&#8217;evento.<\/li><\/ul>\n\n\n\n<ul><li><a href=\"#sdfootnote1anc\">1<\/a> A questi potrebbe essere aggiunta la modalit\u00e0 Q = &#8220;queued&#8221; nel caso di request\/response asincrono in cui \u00e8 responsabilit\u00e0 del fruitore richiedere la risposta all&#8217;erogatore (polling);<\/li><\/ul>\n\n\n\n<p><strong>Intestazione del messaggio di risposta. Il messaggio \u00e8 utilizzato nelle interazioni di tipo richiesta\/risposta, siano esse sincrone o asincrone.<\/strong><\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><img loading=\"lazy\" width=\"300\" height=\"405\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-4.png\" alt=\"\" class=\"wp-image-443\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-4.png 300w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-4-222x300.png 222w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><figcaption>Messaggio \u201cEvento Clinico \u2013 Risposta\u201d<\/figcaption><\/figure><\/div>\n\n\n\n<p>Rispetto alla Intestazione del messaggio di richiesta, questo include i seguenti elementi aggiuntivi (all\u2019interno dell\u2019elemento <em>IntestazioneRisposta<\/em>):<\/p>\n\n\n\n<ul><li><em>RifMessaggio<\/em>: identificativo qualificato del messaggio di richiesta a cui questa risposta si riferisce.<\/li><\/ul>\n\n\n\n<ul><li><em>Acknowledgement<\/em>: \u00e8 il dettaglio dell\u2019acknowledge. L\u2019elemento \u00e8 mostrato in Figura 4. Esso \u00e8 composto da:<ul><li><em>Esito: <\/em>indica complessivamente l\u2019esito della richiesta. Pu\u00f2 assumere uno tra i valori seguenti:<ul><li><em>A = &#8216;Ack&#8217;: <\/em>ricezione e elaborazione avvenuta con successo.<\/li><li><em>W <\/em>= &#8216;Warning&#8217;: il messaggio \u00e8 stato ricevuto ed elaborato ma vi sono alcuni warning (specificati nei dettagli).<\/li><li><em>E = &#8216;Error&#8217;: <\/em>il messaggio \u00e8 stato rifiutato per ragioni che non dipendono dal contenuto del messaggio. Il mittente pu\u00f2 o meno tentare successivamente la ritrasmissione del messaggio in base alle regole stabilite per lo specifico dominio.<\/li><li><em>R = &#8216;Reject&#8217;: <\/em>ricezione e elaborazione non conclusa con successo per ragioni che dipendono dal contenuto del messaggio. Il mittente deve verificare il contenuto del messaggio prima di procedere ad una nuova trasmissione.<\/li><\/ul><\/li><li><em>Dettagli:<\/em> una serie di codici (e descrizioni opzionali) che indicano nel dettaglio l\u2019esito della elaborazione del messaggio. Attualmente sono previsti i seguenti codici:<ul><li>000: Nessun errore.<\/li><li>001: Errore dovuto alla consistenza dei dati come specificato nella Descrizione.<\/li><li>002: OID del mittente sconosciuto.<\/li><li>003: OID del destinatario sconosciuto.<\/li><li>004: Codice RFC di riferimento errato.<\/li><li>005: Numero Scenario RFC non esistente o errato.<\/li><li>006: Modalit\u00e0 di restituzione della risposta non supportata.<\/li><li>007: Messaggio non elaborato perch\u00e9 scaduto.<\/li><li>008: Versione RFC errata.<\/li><\/ul><\/li><\/ul><\/li><\/ul>\n\n\n\n<p><\/p>\n\n\n\n<p><strong>Struttura dell\u2019elemento di acknowledge<\/strong><\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><img loading=\"lazy\" width=\"607\" height=\"119\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-5.png\" alt=\"\" class=\"wp-image-444\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-5.png 607w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-5-300x59.png 300w\" sizes=\"(max-width: 607px) 100vw, 607px\" \/><figcaption>Messaggio \u201cEvento Clinico \u2013 Ack\u201d<\/figcaption><\/figure><\/div>\n\n\n\n<p>Il messaggio di Acknowledge \u00e8 utilizzato in scenari di tipo <em>one-way<\/em> o in scenari di tipo <em>richiesta\/risposta asincrona<\/em>. Scopo del messaggio di Ack \u00e8 restituire, ad un sistema che invia un messaggio, evidenza sull\u2019esito della comunicazione, ricezione ed elaborazione del messaggio stesso.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><img loading=\"lazy\" width=\"623\" height=\"292\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-6.png\" alt=\"\" class=\"wp-image-445\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-6.png 623w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-6-300x141.png 300w\" sizes=\"(max-width: 623px) 100vw, 623px\" \/><\/figure><\/div>\n\n\n\n<p>L\u2019intestazione del messaggio \u00e8 simile a quella del messaggio di risposta. Rispetto a quest\u2019ultimo vi sono le seguenti differenze:<\/p>\n\n\n\n<ul><li>il <em>Corpo<\/em> del messaggio non \u00e8 presente: poich\u00e9 il messaggio di Ack non ha significato dal punto di vista applicativo ma \u00e8 utile solo per ragioni di comunicazione, si assume che il corpo sia mancante e che tutta l\u2019informazione sia all\u2019interno della intestazione.<\/li><li>gli elementi seguenti non sono presenti: <em>Scadenza<\/em> (si assume infatti che un messaggio di Ack non abbia scadenza dal momento che non trasferisce contenuto applicativo), <em>Priorit\u00e0<\/em> e <em>ModalitaAck<\/em>.<\/li><\/ul>\n\n\n\n<p><strong>Messaggio \u201cEvento Clinico \u2013 Accettazione\/Non Accettazione\u201d<\/strong><\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" width=\"543\" height=\"72\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-7.png\" alt=\"\" class=\"wp-image-446\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-7.png 543w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-7-300x40.png 300w\" sizes=\"(max-width: 543px) 100vw, 543px\" \/><figcaption>Struttura del messaggio di Accettazione<\/figcaption><\/figure>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><img loading=\"lazy\" width=\"507\" height=\"74\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-8.png\" alt=\"\" class=\"wp-image-447\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-8.png 507w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-8-300x44.png 300w\" sizes=\"(max-width: 507px) 100vw, 507px\" \/><figcaption>Struttura del messaggio di Non Accettazione<\/figcaption><\/figure><\/div>\n\n\n\n<p>In questa sezione \u00e8 riportata la descrizione del formato del messaggio di <em>Accettazione\/Non Accettazione<\/em> che pu\u00f2 essere ritornato al fruitore del servizio qualora non siano soddisfatte le condizioni minime necessarie per procedere all&#8217;elaborazione (ad esempio la mancanza di validit\u00e0 della busta o del corpo rispetto agli schema di riferimento).<\/p>\n\n\n\n<p>Si osserva che l&#8217;<em>Accettazione<\/em> \u00e8 da intendersi come una <strong>\u201cpresa in carico\u201d<\/strong> (o una mancata presa in carico) dell&#8217;evento da parte di un sistema \u201caccettante\u201d che pu\u00f2 o meno coincidere con l&#8217;erogatore del servizio.<\/p>\n\n\n\n<p>In ogni caso, essa ha significato <strong>diverso<\/strong> rispetto al messaggio di <em>Evento Clinico \u201cAck\u201d<\/em> descritto nella precedente sezione che si riferisce invece all&#8217;esito della <strong>elaborazione<\/strong> dell&#8217;evento da parte dell&#8217;erogatore del servizio.<\/p>\n\n\n\n<p>Si osserva inoltre che mentre il messaggio di Ack pu\u00f2 essere restituito al fruitore del servizio in modo sincrono o asincrono rispetto alla richiesta, il messaggio di <em>Accettazione<\/em> \u00e8 sempre restituito in modo sincrono.<\/p>\n\n\n\n<p>Come mostrato nelle precedenti figure, la struttura dei due messaggi \u00e8 la stessa, fatta eccezione per l&#8217;elemento radice.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" width=\"1024\" height=\"144\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-11-1024x144.png\" alt=\"\" class=\"wp-image-450\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-11-1024x144.png 1024w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-11-300x42.png 300w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-11-768x108.png 768w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-11.png 1046w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" width=\"1024\" height=\"144\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/123-1024x144.jpg\" alt=\"\" class=\"wp-image-451\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/123-1024x144.jpg 1024w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/123-300x42.jpg 300w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/123-768x108.jpg 768w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/123.jpg 1046w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><figcaption>Struttura interna del messaggio di Accettazione\/Non Accettazione<\/figcaption><\/figure>\n\n\n\n<p>Come per messaggi di <em>Richiesta<\/em> e <em>Risposta<\/em>, anche il messaggio di <em>Accettazione<\/em> si compone di una \u201cIntestazione\u201d e un \u201cCorpo\u201d opzionale.<\/p>\n\n\n\n<p>L&#8217;<em>Intestazione<\/em> riporta l&#8217;esito della accettazione attraverso le seguenti informazioni:<\/p>\n\n\n\n<ul><li><em>Esito<\/em>: pu\u00f2 assumere uno tra i valori seguenti:<ul><li>A = &#8216;Ack&#8217;: ricezione e elaborazione da parte del sistema accettante avvenuta con successo.<\/li><li>W = &#8216;Warning&#8217;: il messaggio \u00e8 stato accettato ma vi sono alcune segnalazioni (riportate nell&#8217;elemento \u201cDettaglio Esito\u201d).<\/li><li>R = &#8216;Reject&#8217;: messaggio non accettato per ragioni che dipendono dal contenuto del messaggio. Il mittente deve verificare il contenuto del messaggio prima di procedere ad una nuova trasmissione.<\/li><li>E = &#8216;Error&#8217;: il messaggio non \u00e8 stato accettato per ragioni che non dipendono dal contenuto del messaggio. Il mittente pu\u00f2 o meno tentare la ritrasmissione successivamente del messaggio in base alle regole stabilite per lo specifico dominio.<\/li><\/ul><\/li><li><em>Dettaglio Esito<\/em>: una sequenza di codici che forniscono dettagli sull\u2019esito del processo di accettazione. Per ogni codice \u00e8 possibile fornire anche una descrizione.<br>I codici attualmente previsti sono i seguenti:<ul><li>000: Messaggio accettato.<\/li><li>001: Busta non valida rispetto agli schema XML di riferimento della busta &#8216;Evento Clinico&#8217; (RFC 98).<\/li><li>002: Identificativo OID del mittente sconosciuto.<\/li><li>003: Identificativo OID del destinatario sconosciuto.<\/li><li>004: Codice RFC di riferimento errato.<\/li><li>005: Numero Scenario RFC non esistente o errato.<\/li><li>006: Modalit\u00e0 di restituzione della risposta\/ack non supportata.<\/li><li>007: Messaggio scaduto.<\/li><li>008: Versione RFC errata.<\/li><li>009: Il messaggio \u00e8 stato accettato ma non \u00e8 stato possibile completare con successo il processo di anonimizzazione. L&#8217;evento viene inoltrato senza essere associato ad un soggetto.<\/li><li>101: Contenuto applicativo (Body) non valido rispetto agli schema XML di riferimento.<\/li><li>500: Errore generico.<\/li><li>501: Errore nella trasmissione del messaggio.<\/li><li>502: Errore nella anonimizzazione dell&#8217;evento.<\/li><\/ul><\/li><\/ul>\n\n\n\n<p>Il <em>Corpo<\/em> \u00e8 un elemento opzionale di cui non \u00e8 specificata la struttura. Il contenuto del Corpo, se presente, \u00e8 definito dagli RFC applicativi di riferimento.<\/p>\n\n\n\n<p>All&#8217;interno del corpo di un messaggio di accettazione potrebbe ad esempio essere inserita la busta di e.Gov restituita da CART al sistema accettante (es. un proxy applicativo) a seguito della propagazione del messaggio all&#8217;erogatore del servizio.<\/p>\n\n\n\n<p>All&#8217;interno del corpo di un messaggio di accettazione potrebbe ad esempio essere inserita la busta di e.Gov restituita da CART al sistema accettante (es. un proxy applicativo) a seguito della propagazione del messaggio all&#8217;erogatore del servizio.<\/p>\n\n\n\n<p><\/p>\n\n\n\n<p>Si illustrano di seguito le principali primitive di cooperazione tra un sistema <em>Origine<\/em> del messaggio e un sistema <em>Destinazione<\/em> e i messaggi scambiati nelle interazioni.<\/p>\n\n\n\n<p>Nello scenario Richiesta\/Risposta sincrono, il sistema <em>Origine<\/em> invia la richiesta che viene elaborata dal destinatario. Il destinatario restituisce quindi in modo sincrono la risposta all\u2019<em>Origine<\/em>, riportando il corretto riferimento al messaggio ricevuto (<em>RifMessaggio<\/em>).<\/p>\n\n\n\n<p>Si osserva che la risposta contiene anche l\u2019Acknowledge che riporta l\u2019esito della ricezione ed elaborazione del messaggio.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large is-resized\"><img loading=\"lazy\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-12.png\" alt=\"\" class=\"wp-image-452\" width=\"469\" height=\"234\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-12.png 469w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-12-300x150.png 300w\" sizes=\"(max-width: 469px) 100vw, 469px\" \/><figcaption>scenario di cooperazione Richiesta\/Risposta sincrono<\/figcaption><\/figure><\/div>\n\n\n\n<p>Nello scenario one-way, il sistema <em>Origine<\/em> invia la richiesta verso l\u2019infrastruttura (che nell&#8217;esempio assume il ruolo di sistema di accettazione). L&#8217;infrastruttura effettua i controlli di accettazione e, se questi si concludono con un esito positivo, restituisce in modo sincrono la ricevuta di <em>Accettazione<\/em> al sistema <em>Origine <\/em>propagando anche la richiesta al sistema di <em>Destinazione<\/em>. Il sistema di <em>Destinazione<\/em> riceve quindi la richiesta in modo asincrono rispetto alla spedizione, la elabora ed eventualmente invia il messaggio di <em>Ackowledge<\/em> al sistema <em>Origine<\/em> per mezzo dell&#8217;<em>Infrastruttura<\/em> riportando il corretto riferimento al messaggio ricevuto (<em>RifMessaggio<\/em>) e l\u2019esito della ricezione ed elaborazione del messaggio.<\/p>\n\n\n\n<p>Si osserva che il messaggio di Ack viene inviato al sistema Origine solo nei casi seguenti:<\/p>\n\n\n\n<ul><li>Il messaggio di richiesta contiene <em>Modalit\u00e0 di Ack=\u2019S\u2019;<\/em><\/li><li>Il messaggio di richiesta contiene <em>Modalit\u00e0 di Ack=\u2019E\u2019<\/em> e si \u00e8 verificato un problema presso il sistema destinatario, oppure il messaggio di richiesta \u00e8 arrivato ormai scaduto. In questi casi il messaggio di Ack riporta Esito = \u2018E\u2019 (Error) o R = &#8216;R\u2019 (Reject);<\/li><\/ul>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter size-large\"><img loading=\"lazy\" width=\"525\" height=\"319\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-13.png\" alt=\"\" class=\"wp-image-453\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-13.png 525w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-13-300x182.png 300w\" sizes=\"(max-width: 525px) 100vw, 525px\" \/><figcaption>scenario di cooperazione one-way (con acknowledge)<\/figcaption><\/figure><\/div>\n\n\n\n<p>Nello scenario richiesta-risposta asincrono (mostrato nella seguente Figura 11), il sistema <em>Origine<\/em> invia la richiesta verso l\u2019infrastruttura e ne riceve in modo sincrono la ricevuta di <em>Accettazione<\/em> (interazioni 1,2), cos\u00ec come descritto nello scenario precedente. Il sistema di <em>Destinazione<\/em> riceve la richiesta in modo asincrono rispetto alla spedizione (interaz. 3), la elabora (4) ed invia successivamente il messaggio di <em>Risposta <\/em>al sistema <em>Origine<\/em> per mezzo dell&#8217;<em>Infrastruttura <\/em>(interazione 5, 6) riportando il corretto riferimento al messaggio ricevuto (<em>RifMessaggio<\/em>), e l&#8217;esito della elaborazione del messaggio.<\/p>\n\n\n\n<p>Alla ricezione del messaggio di <em>Risposta<\/em> (interaz. 7), il sistema <em>Origine<\/em> pu\u00f2 generare un <em>Acknowledge<\/em> in direzione del sistema <em>Destinazione<\/em> per confermare la corretta ricezione\/acquisizione della risposta (interaz. 9-11).<\/p>\n\n\n\n<p>Si osserva che il messaggio di <em>Acknowledge<\/em> viene inviato dal sistema <em>Origine<\/em> al sistema <em>Destinazione<\/em> solo nei casi seguenti:<\/p>\n\n\n\n<ul><li>Il messaggio di <em>Risposta<\/em> contiene <em>Modalit\u00e0 di Ack=\u2019S\u2019;<\/em><\/li><li>Il messaggio di <em>Risposta<\/em> contiene <em>Modalit\u00e0 di Ack=\u2019E\u2019<\/em> e si \u00e8 verificato un problema presso il sistema <em>Origine<\/em>, oppure il messaggio di <em>Risposta<\/em> \u00e8 arrivato ormai scaduto. In questi casi il messaggio di Acknowledge riporta Esito = \u2018E\u2019 (Error) o R = &#8216;R\u2019 (Reject);<\/li><\/ul>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" width=\"580\" height=\"439\" src=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-14.png\" alt=\"\" class=\"wp-image-454\" srcset=\"https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-14.png 580w, https:\/\/compliance.toscana.it\/wordpress\/wp-content\/uploads\/2021\/06\/image-14-300x227.png 300w\" sizes=\"(max-width: 580px) 100vw, 580px\" \/><figcaption>Scenario di interazione richiesta \/ risposta asincrono con Acknowledge<\/figcaption><\/figure>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Specifiche della busta di trasporto degli eventi sanitari, di seguito chiamata anche \u201cEvento Clinico\u201d.<\/p>\n","protected":false},"author":2,"featured_media":469,"template":"","meta":[],"_links":{"self":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/scenario\/434"}],"collection":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/scenario"}],"about":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/types\/scenario"}],"author":[{"embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/users\/2"}],"version-history":[{"count":4,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/scenario\/434\/revisions"}],"predecessor-version":[{"id":527,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/scenario\/434\/revisions\/527"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/media\/469"}],"wp:attachment":[{"href":"https:\/\/compliance.toscana.it\/wordpress\/wp-json\/wp\/v2\/media?parent=434"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}